TOS Silver 2000

home *** CD-ROM | disk | FTP | other *** search

/ TOS Silver 2000 / TOS Silver 2000.iso / Tools / frdm205d / LIBERTY / DOKU / LIBERTY.TXT < prev

Wrap

Text File | 1998-09-20 | 56.0 KB | 1,324 lines

Liberty Dokumentation zur Version 1.31 20.09.1998 von Christian Krüger Im Erpelgrund 16 13503 Berlin Internet: chris@pace.de Inhaltsverzeichnis ================== 1 Rechtliches / Copyright 1.1 Haftungsausschluß 1.2 Warenzeichen 1.3 Spenden 2 Installation 2.1 Bootreihenfolge 3 Was ist Liberty? 4 Was bietet Liberty? 4.1 CJar-Erweiterung 4.2 Soundfunktionen 4.3 Vektorgrafikfunktionen 4.3.1 Der Konvertierer GM2CKVDI 5 An die programmierenden Zunft 5.1 Allgemeines 5.1.1 Parameterübergabe 5.2 Der Liberty-Cookie & XBIOS-Erweiterung 5.3 Die Liberty-Struktur 5.4 Die Utility-Funktionen 5.4.1 Init_Liberty(); 5.4.2 lock_Sema(); 5.4.3 release_Sema(); 5.4.4 memcpy(); 5.4.5 memset(); 5.5 Die 'GEMDOS-Erweiterungen' 5.5.1 CK_init_meminfo() 5.5.2 CK_malloc() 5.5.3 CK_realloc() 5.5.4 CK_free() 5.5.5 CK_load_buffer() 5.6 Die 'VDI-Erweiterungen' 5.7 Die 'AES-Unterstützung' 5.8 Die Sound-Funktionen 5.9 Programmbeispiel 6 Ausblick 7 Changes 8 Kontaktadresse 1 Rechtliches / Copyright ************************** Das Copyright an Liberty und dieser Dokumentation liegt bei Christian Krüger, Berlin. Die Weitergabe des Programms ist Grundsätzlich frei (Stichwort FREEWARE), dennoch sind folgende Punkte zu beachten: ∙ Das Programm darf nur mit allen zugehörigen Dateien und in *unveränderter* Form weitergegeben werden. Entweder unkomprimiert oder als 'Zip'-Archiv. Folgende Dateien müssen folglich im Archiv enthalten sein (-> = Ordner): LIBERTY -> AUTO -> LIBERTY.PRG DEVELOP -> IBMR.H VDICODES.H DOKU -> HTML -> LIBERTY.HTM LIBERTY.GIF MYSELF.GIF UDO_LF.GIF UDO_RG.GIF UDO_UP.GIF LIBERTY.TXT LIBERTY.H LIBERTY.HYP MCSNDPAT -> MACSND.DFY PATCHY.TTP SIZEJAR.TTP GM2CKVDI.TTP ∙ Das Programm darf generell nur kostenlos weitergegeben werden. Der Upload in gebührenfreie Mailboxen und auf nichtkommerzielle FTP-Server ist erlaubt und erwünscht. ∙ Dem Archiv dürfen keine weiteren Dateien hinzugefügt werden, insbesondere keine Mailboxwerbung und keine Werbung für PD- Serien. Die Umbenennung oder das Umpacken des Archivs ist unerwünscht. ∙ Das Programm darf anderen Programme beigelegt werden - unter der Voraussetzung, daß ich *vor der Veröffentlichung* darüber informiert werde und ein eindeutiger Hinweis auf die Versions- nummer der beigefügten Liberty-Version erfolgt (z.B. hervorgehoben im 'README'). Auch hier gilt obiges 'Vollständigkeitsprinzip'! ∙ Für die Weitergabe auf Disketten im Rahmen einer Public-Domain- Serie dürfen keine Gebühren verlangt werden, die einen Betrag von 10 DM (exklusive Versandkosten) überschreiten. ∙ Die Weitergabe via CD-ROM darf nur dann ohne schriftliche Genehmigung erfolgen, wenn der Preis der CD pro bespieltem MegaByte 0.1 DM nicht übersteigt! 1.1 Haftungsausschluß ====================== Trotz sorgfältiger Entwicklung und umfangreichen Tests kann keine Gewährleistung für die Richtigkeit des Inhalts dieser Dokumentation und die einwandfreie Funktion von "Liberty" übernommen werden. Der Autor kann keine Haftung für irgendwelche direkten oder indirekten Schäden - einschließlich aber nicht beschränkt auf materielle oder finanzielle - übernehmen, die durch die Benutzung von "Liberty" oder dessen Untauglichkeit für einen bestimmten Zweck entstehen. 1.2 Warenzeichen ================= Innerhalb dieser Dokumentation wird auf Warenzeichen Bezug genommen, die nicht explizit als solche ausgewiesen sind. Aus dem Fehlen einer Kennzeichnung kann nicht geschlossen werden, daß ein Name frei von den Rechten Dritter ist. 1.3 Spenden ============ Wie schon erwähnt ist Liberty Freeware. Ich habe aber selbst- verständlich nichts gegen TOS-Programmentwicklungsstützungskäufe ;-). Wer mit also eine motivationssteigernde Spende zukommen lassen möchte, kann das über die Kontaktadresse tun. Wer keine Lust hat etwas zu spenden und trotzdem meine Motivation steigern möchte, der sollte sich 'Freedom2' kaufen. Dann bekommt man wenigstens etwas für's Geld ;-) ... 2 Installation *************** *(Bitte dieses Kapitel komplett _vor_ der Installation durchlesen!)* Kopieren Sie einfach 'LIBERTY.PRG' in den AUTO-Ordner ihres Boot- Laufwerkes. Nach dem Kopieren von 'LIBERTY.PRG' und dem folgenden Systemstart installiert sich dann die Library automatisch. 2.1 Bootreihenfolge ==================== 'LIBERTY.PRG' sollte physikalisch möglichst früh im AUTO-Ordner stehen, auf jeden Fall vor (wenn Sie es denn einsetzen) MiNT! Viele Bootselektoren (z.B. XBOOT) erlauben es, konfortabel die Bootreihenfolge der AUTO-Ordner Programme zu verändern. Sollten Sie nicht in Besitz eines solchen Programms sein hilft folgendes: Betrachten Sie sich ihren AUTO-Ordner im Desktop in unsortierter Ausgabeart. Hier sollte 'LIBERTY.PRG' möglichst weit vorne stehen. Ein Ändern der Bootreihenfolge erreichen Sie durch Verschieben des kompletten AUTO-Ordners in ein anderes Verzeichnis und dem Zurückverschieben aller AUTO-Ordner-Programme in gewünschter Reihenfolge in den AUTO-Ordner. (Wer absolut nicht versteht was ich meine, kann mich unter später genannter Adresse kontaktieren.) MagiCMac Benutzer müssen den Umweg über Umbenennen der Dateien oder Bootreihenfolgedatei (wie in der MagiCMac Dokumentation beschrieben) gehen um Liberty möglichst früh zu initalisieren (MiNT wird wohl keiner auf Macs benutzen ;-) ). 3 Was ist Liberty? ******************* Liberty ist eine residente Systemerweiterung. Das bedeutet, daß eine Vielzahl von Funktionen die in Liberty vorhanden sind, anderen Programmen angeboten werden. Das bloße Vorhandensein von Liberty ändert nicht viel an Ihrem System, sondern die Funktionen der Library (oder auch Systemerweiterung, folgend Lib genannt) müssen von anderen Programmen genutzt werden. Freedom2 ist z.B. ein solches Programm. Freedom2 benutzt viele der Liberty-Funktionen, so daß es ohne diese Lib nicht lauffähig ist. Nun gibt es (oft zurecht) viele Gegner solcher Systemerweiterungen. Die Argumente gegen den Einsatz einer residenten Erweiterung sind meistens folgende: ∙ residente Systemerweiterungen schlucken permanent Speicher, auch wenn sie nicht benötigt werden ∙ residente Systemerweiterungen werden oftmals nur von wenigen Programmen unterstützt und viele Funktionen der Erweiterung werden nicht benötigt, was dann ebenfalls Speicherverschwendung bedeutet ∙ residente Systemerweiterungen sind groß, klobig und unflexibel; bei Zugriff von mehreren Programmen auf eine Funktion der Erweiterungen gibt es oft Probleme oder der Rechner wird 'gebremst' (Experten mögen mir verzeihen, daß ich hier nicht von Semaphoren spreche :-) ) Die Vorteile solcher Erweiterungen: ∙ das 'Rad' muß nicht tausendmal neu erfunden werden; Programme können die angebotenen Funktionen einfach benutzen ohne zu wissen was sie (die Funktionen ;-)) genau machen (daraus folgt eine wesentlich kürzere Entwicklungszeit und (hoffentlich) mehr Spaß am Programmieren, da man sich auf die programmspezifischen Probleme konzentrieren kann) ∙ benutzen viele Programme die Systemerweiterung gibt es einen Speicherspareffekt: die von vielen Programmen benötigten Routinen der Systemerweiterung sind nur einmal im Speicher und nicht in jedem der Programme extra vorhanden. Liberty hat natürlich diese Vorteile und entkräftet zusätzlich mit seiner Art des Aufbaus die Nachteile: ∙ Liberty verbraucht weniger als 30kB Speicher! (ist also kein 'grober Klotz' wie andere Libs die gleich 300kB oder mehr an Speicher verschlingen) ∙ Liberty konzentriert sich auf die wesentlichsten Mankos des Betriebsystems und beseitigt sie; es ist keine GEM-Interface- Library! (wäre wohl auch sinnlos zu versuchen alle GEM-Lib- Programmier- Süppchen zu einem Standard zu vereinigen ;-) ) ∙ fast alle Funktionen der Lib werden von Freedom2 benutzt (wer kommt schon ohne aus? ;-) ); von Speicherverschwendung kann bei Einsatz von Freedom2 folglich nicht gesprochen werden (bei 30kB ist dieses ohnehin schon ziemlich unglaubwürdig); bereits bei Einsatz eines zweiten Programms welches Liberty benutzt, tritt der gewünschte Speicherspareffekt ein ∙ Liberty besteht zu 90% aus hochoptimierten Assembler-Routinen; nur so konnte die Kürze und Geschwindigkeit der Erweiterung erreicht werden ∙ alle Funktionen von Liberty sind reentrant und 90% der Funktionen sind 'Multi-Threading'-fähig (d.h. mehrere Programme können gleichzeitig eine Funktion von Liberty benutzen ohne sich dabei gegenseitig zu stören oder zu blockieren) Überzeugt? 4 Was bietet Liberty? ********************** Liberty setzt sich aus Funktionen mit den unterschiedlichsten Aufgabengebieten zusammen. Obwohl daher das Funktionsangebot vielleicht etwas zusammengewürfelt scheint, ist dem nicht so. Wie schon erwähnt versucht Liberty die nervensten Schwächen des Betriebsystems auszugleichen: Funktionen, die immer wieder programmiert oder eingebunden werden müssen und die viele Programme benötigen. Das diese Schwächen nicht konzentriert an einer Stelle des Betriebssystems auftreten ist logisch. So besteht die Lib intern aus folgenden Teilen: XBIOS-Erweiterung bzw. Nutzung: ∙ CJar-kompatibele XBIOS Erweiterung, die auf komfortabele Weise das Erzeugen, Abfragen und Löschen von 'Cookies' ermöglicht ∙ Soundfunktionen welche eine rechnerunabhängige Tonausgabe garantieren Erweiterungen mit GEMDOS-Charakteristik: ∙ eine sehr effiziente und schnelle Speicherverwaltung, die privaten, globalen, normalen und alternativen Speicher (wenn nötig) unterscheidet und kleinere Speicherblöcke in größeren verwaltet sowie für ein dauerhaftes, sicheres 'malloc' für ACCs unter SingleTOS sorgt ∙ eine Routine zum Laden einer Datei in einen Puffer (sollte die Datei mit ATOMIK 3.5 gepackt sein, so wird diese automatisch ausgepackt!) Erweiterungen mit VDI-Charakteristik: ∙ eine Vielzahl von sehr schnellen Rastergrafikfunktionen (Laden von XIMG/GIF, Skalieren etc.) ∙ Vektorgrafikfunktionen (Translation, Rotation, Skalierung, ...) - damit sind endlich auf einfache und komfortabele Weise Vektoricons realisierbar AES-Unterstützung: ∙ Funktionen zum einfachen Einhängen von Funktionen in einzelne AES- Calls (mit Applikationszustandslisten!) ∙ LIBERTY ist in der Lage (auch wenn kein Programm Liberty benutzt) defekte AES-Calls (nicht initalisiertes Global-Field) zu reparieren! Damit wird u.a. erreicht, daß z.B. der Dateiselektor Freedom auch von ('Schweine'-)Programmen aufgerufen werden kann, bei denen sonst die normale Dateiauswahlbox erscheinen würde! 4.1 CJar-Erweiterung ===================== Liberty legt beim Start im AUTO-Ordner automatisch einen 'Cookie-Jar' an. Programme die dieses sonst übernommen haben ('CJARxxx.*' etc.) sind damit überflüssig! Ebenfalls, das für den MiNT Aufsatz 'Geneva' benötigte 'JARxxx.PRG' ist unnötig. In Liberty sind die Fähigkeiten dieses Programms enthalten! (JARxxx wurde getestet, für gut befunden und die Funktionalität (erweitert) aufgenommen.) Die Größe des 'Cookie-Jar' kann mit dem beigefügten Programm 'SIZEJAR.TTP' verändert werden. In der Grundeinstellung wird beim Start von Liberty für 32 zusätzliche 'Kekse' (zu den aktuell vorhandenen Systemcookies) Platz geschaffen. Diesen Wert kann man wiefolgt ändern: 1. Man kopiert 'SIZEJAR.TTP' in das Verzeichnis in dem 'LIBERTY.PRG' steht (also normalerweise in den AUTO-Ordner). 2. Man startet das Programm durch Doppelklick und gibt dann die gewünschte Anzahl an Keksen als Zahl in den erscheinenden Dialog ein. 3. Nach Beendigung des Programms muß man 'SIZEJAR.TTP' wieder aus dem AUTO-Ordner entfernen. 4. Beim Neustart des Systems berücksichtigt dann Liberty die angegebene Anzahl. Fertig! In der Regel sollte dieses Vorgehen jedoch unnötig sein, da 32 (zusätzliche) Kekse ausreichen und auch keine große Speicherverschwendung darstellen. 4.2 Soundfunktionen ==================== Liberty bietet eine komfortable und *einheitliche* Schnittstelle zur Soundausgabe. Mit Hilfe dieser Erweiterung können (bald) alle Benutzer von Atari-Kompatiblen in den Genuß eines klangvollen Erlebnisses kommen. Die Zeiten bei denen Programme die Soundausgabe auf bestimmte Systeme einschränken, oder diese nur mit /käuflichen/ Programmen garantieren, sollten damit für immer vorbei sein. Realisiert wurde die Soundausgabe schon für Rechner mit DMA-Sound ((Mega)STE/TT), FalconO3O sowie für Apple-Rechner mit 'MacSound'. Rechner mit PSG-(Emulation) folgen demnächst. Bisher hatte ich noch keinen Kontakt zu Medusen oder dem Hades, halte hier aber eine Anpassung für die exisiterende Soundkarte ebenso wie für PC's mit XBIOS-Treiber möglich (...legt STARTRACK ein McSn-Keks an? - Dann funktioniert auch mit dieser Karte schon die Sound- Ausgabe...). Wichtig ist nur, daß sich ein Anwenderprogrammierer keine Gedanken mehr um evt. Soundfähigkeiten des Rechners machen muß. Das Vorhandensein von Liberty garantiert ein Ansprechen der Soundfunktionen, auch wenn diese ohne Treiber funktionslos bleiben. _*Zum Patchprogramm für MacSound (nur für Apple-Rechner):*_ MacSound (ein Autoordnerprogramm welches MagiCMac beiliegt und XBIOS- Soundfunktionen zur Verfügung stellt) ist leider nicht so mächtig wie es anderen Programmen gegenüber vorgibt. Um korrektes Funktionieren zu gewährleisten, ist es daher nötig MacSound zu patchen. Eine Patchdatei mit dem entsprechenden Patchprogramm befindet sich im Ornder 'MCSNDPAT'. Um MacSound zu patchen, muß man folgendermaßen vorgehen: ∙ Zunächst 'MACSND.PRG' (müßte im Auto-Ordner liegen) in das 'MCSNDPAT'-Verzeichnis verschieben. ∙ Nun die Datei 'MACSND.DFY' auf das Programm 'PATCHY.TTP' im gleichen Verzeichnis ziehen und fallenlassen (Drag&Drop). ∙ Anschließend das Programm 'MACSND.PRG' aus diesem Verzeichnis (welches nun angepasst ist) wieder in den Auto-Ordner verfrachten. MagiCMac neustarten, fertig! Falls irgendwelche Fehler auftreten sollten, handelt es sich wohl nicht um die Version 1.0 von MacSound (nur diese kann gepatcht werden)! Sollte man eine ältere Version haben, unbedingt die neuere besorgen. Ob eine neuere Version als die 1.0 existiert (wenn ja bitte melden!), kann ich nicht sagen, mir ist jedenfalls keine bekannt. Der Patch setzt die Versionsnummer übrigens auf 1.01 herauf! /Bei Fragen oder Hinweisen zu diesem Thema bitte die Kontaktadresse benutzen!/ Nach dem Patchen wurde im Verzeichnis 'MCSNDPAT' das Verzeichnis 'PATCHED' angelegt, welches die Ursprungsversion von MacSound enthält. Eine Sicherungskopie der Originals wird also automatisch erzeugt. /An dieser Stelle Dank an Christian Wempe & Holger Weets für ihr Patchprogramm 'DIFFY' bzw. 'PATCHY'. Ich hoffe es ist Ok, daß ich 'PATCHY' einfach so (einzeln - um Verwirrung zu vermeiden...) beigefügt habe (in eurer Doku steht zu diesem Thema leider nichts), schließlich ist Liberty ja auch Freeware. Das komplette Archiv zu 'Diffy 2' sollte man in jeder guten 'Maus / ftp-site' finden./ Ein kleiner Soundtest der Liberty-Funktionen gefällig? Den Info-Dialog von Freedom2 aufrufen (Klick mit der rechten Maustaste auf das Freedom2-Logo bei *installiertem* Konfig.CPX) und anschließend das große Freedom2-Logo im Info-Dialog anklicken... Wenn sie einen (Mega)STE/TT/FalconO3O oder MagiCMac mit gepatchtem MacSound benutzen, dann müßten sie was 'Nettes' gehört haben... 4.3 Vektorgrafikfunktionen =========================== Vektorzeichensätze und Bezierkurven sollten heutzutage eine Selbst- verständlichkeit sein. So werden diese Befehle auch von den Vektorgrafikfunktionen in Liberty ordnungsgemäß verarbeitet. Leider ist das Original-VDI (der Betriebssystemteil der für die Ausgabe von Grafiken verantwortlich ist) nicht in der Lage diese Befehle zu verarbeiten und ignoriert sie völlig. Das bedeutet, daß wenn ein Programm die Vektorgrafikdarstellungs- funktionen von Liberty benutzt und die darzustellende Grafik Bezierkurven und/oder Vektorzeichensätze enthält, das Ergebnis auf dem Bildschirm nicht der Originalgrafik entspricht. Dieses trifft aber selbstverständlich nur für VDIs zu, die diese Befehle nicht verstehen! Wie alle Funktionen von Liberty sind auch die Vektorgrafikfunktionen auf Geschwingidkeit getrimmt. Bei der Vektorgrafikausgabe wurde z.B. ein großer Geschwindigkeitsvorteil dadurch erreicht, daß die Ausgabe _direkt_ an das VDI geleitet wird und die Befehle nicht erst durch einen TRAP geschickt werden! Das dabei verwendete Verfahren ist keinenfalls 'schweinisch' sondern bekannt! (Für die Experten: Man läd das Register D0 mit -1 und macht einen TRAP #2 Aufruf. Als Ergebnis erhält man die Einsprungsadresse des VDI-Dispatchers.) VDI-Erweiterungen, die das VDI hinsichtlich z.B. einer Bezierkurvenausgabe erweitern, müssen dieses Verfahren unterstützen (Profibuch, 10. Auflage, Seite 298 unten)! 'NVDI' (da sauber) hat damit keine Probleme und in Verbindung mit diesem VDI klappt die Ausgabe obiger Befehle wunderbar (auch wenn 'NVDI' nur als GDOS eingesetzt wird)! Leider kann man das vom 'SpeedoGDOS' nicht behaupten. Diese VDI-Erweiterung versäumt es offensichtlich obiges Verfahren zu unterstützen und somit ist dieses Ausgabesystem für Liberty praktisch nicht vorhanden (keine Bezierkurven und keine Vektorzeichensätze!!!). Ich weiß, daß diese Tatsache sicherlich einige Leute ziemlich verärgert und möchte deshalb hier Forderungen nach 'konformer' Ausgabe über den TRAP vorbeugen: ∙ die oben beschriebene Vorgehensweise ist konform, da sie bekannt ist und es offensichtlich auch ein Ausgabesystem gibt (NVDI), welches damit keine Probleme hat; Liberty ist folglich unschuldig, das Problem liegt beim unvollständigem Ausgabesystem (SpeedoGDOS) ∙ ein Abändern der Liberty-Vektorgrafikausgabe brächte unzumutbare Geschwindigkeitseinbußen für Benutzer mit konformen Ausgabesystemen ∙ ich habe wenig Lust die Fehler anderer Programmierer auszubügeln... Meine Empfehlung an SpeedoGDOS-Fanatiker die programmieren können: Programmiert ein Utility welches sich in den TRAP #2 hängt, die -1 abfängt und die Adresse des SpeedoGDOS-Dispatchers zurückliefert. Dann klappt's auch mit Liberty... ;-) 4.3.1 Der Konvertierer GM2CKVDI -------------------------------- Um GEM-Metafiles in das Liberty-Vektorformat umzuwandeln ist ein Konvertierer beigefügt (GM2CKVDI.TTP). Das Liberty-Vektorgrafikformat kann mehrere einzelne Grafiken enthalten, welche es interessant für Vektoricons machen. Da GEM-Metafiles oft sehr 'großzügig' und unpräzise erzeugt werden, ist es nicht ausgeschlossen, daß der Konvertierer bei einigen Dateien ziemlich komische Ergebnisse erzeugt. Dieses ist abhängig vom Programm mit dem die Dateien erzeugt wurden. Ausgerichtet ist der Konvertierer auf Dateien die mit 'Kandinsky (2.01)' kreiert wurden. Hiermit werden korrekte Ergebnisse erzielt. _Der Aufruf:_ GM2CKVDI -[cpnswm16h?] metafilename Die übergebene Datei _muß_ mit '.GEM' enden. Die Zieldatei wird im Verzeichnis der Quelldatei erzeugt und erhält je nach angegebenem Zieltyp die Dateiendung '.CVD' oder '.C'. _Die Optionen:_ Für den Übersetzungsvorgang existieren einige Optionen: -h,-help,-? zeigt eine kurze Hilfe mit Erläuterung der Optionen an -n setzt im Header der Zieldatei den Namen der Grafik. Dieser Name kann auch über die Grafik darselbst definiert sein, indem die Grafik mit dem speziellen Text '((CN))/NAME/' versehen wird. Dieser Textbefehl wird _nicht_ übersetzt und dient lediglich zum Setzen des Vektorgrafiknamens im Zieldateikopf. -s # setzt den Größenmaßstab. Dieser legt die maximale Ausdehnung der zu erzeugenden Datei fest. Mit diesem Wert wird natürlich auch die Quantisierung der Grafikkoordinaten in der Zieldatei bestimmt. Der Defaultwert ist 255. Der übergebene Wert darf zwischen 1 und 32000 liegen. -c die Zieldatei wird nicht als Binärfile sondern als C- Quellcode abgelegt. Besonders dann praktisch, wenn man die Vektordaten in ein Programm mit einbinden möchte. Um die Vektordaten einbinden zu können, benötigt man die '.h'-Dateien im Ordner 'DEVELOP'. Die Dateiendung der Zieldatei ist in diesem Modus '.C'. -m die angegebene Quelldatei enthält mehrer Vektorgrafiken die umgewandelt werden sollen (z.B. bei Vektoricondateien). Der Konvertierer erkennt die einzelnen Vektorgrafiken in einer solchen Datei daran, daß die diversen Vektorgrafikobjekte als 'Top-Level- 'Gruppe definiert worden sind (Kandinsky: Gruppieren). Als 'Top-Level' bezeichne ich alle Gruppen die direkt, ohne weitere Gruppenauflösung in der Vektorgrafik erreichbar sind. Diese 'Top-Level-Gruppen' dürfen folglich problemlos in ihrer (internen) Struktur weitere Objektgruppen enthalten. Top-Level-Gruppen werden dann jeweils in der Zieldatei als eigenständige Vektorgrafiken verkettet. Da es sinnvoll ist, den Grafiken eigene Namen zu verleihen und über die Option -n nur ein Name gesetzt werden kann, solte man in jeder Gruppe den Spezialtext '((CN))/NAME/' ablegen um die einzelne Grafik später identifizieren zu können. /Die Vorhergehensweise wird klarer, wenn man eine GEM- Meta-Datei des Dateiselektors Freedom2 untersucht (liegen in der Freedom2-Distribution im Ordner 'VICON\SRC\')./ -16 Farbfixierung nur mit den ersten 16 (Standard-)VDI- Farben vornehmen. Beim Umwandlungsvorgang werden die Farben der GEM-Metadatei die noch als Farbanteile beschrieben sind in absolute VDI-Indizes umgewandelt. Dieses geschieht nach dem Verfahren 'Best-Fit' mit der aktuellen Farbpalette. Da es nun nicht ausgeschlossen ist, daß die benutzten Farben der GEM-Metadatei leicht von den 16 unteren Systemfarben abweichen und als bestpassenste Farben Farben mit einem Index >16 gefunden werden, kann man die Suche auf die ersten 16 Farben mit diesem Schalter beschränken. Da die ersten 16 Farben von DR festgeschrieben sind, kann man so eine 'farbportable' CVD-Datei erzeugen. -w Anzeige des Konvertierungsvorgangs. Alle Übersetzten VDI-Befehle werden auf dem Bildschirm ausgegeben. Hauptsächtlich ist der Konvertierer (wie man vielleicht festgestellt haben wird) für ambitionierte Anwender und Programmierer interessant. 5 An die programmierenden Zunft ******************************** Sie sind Programmierer, die Featureliste von Liberty hat Sie locker vom Hocker geworfen und Sie sagen sich:"Eine tolle Library, die will ich auch unterstützen!" /Kein Problem!/ Einzige Voraussetzung um die Library benutzen zu dürfen: Ich erhalte ein kostenloses Exemplar des Programms welches die Library benutzt! Software die den Status 'Public Domain', 'Freeware' oder 'Fairware' hat, ist davon natürlich ausgenommen ;-). In der letzten Doku zu Liberty habe ich noch von einer seperaten Dokumentation für Programmierer gesprochen. Da die Resonanz aber unerwartet groß war und ich mir die Arbeit zwei Dokumentationen zu pflegen ersparen möchte, wird die Beschreibung der Liberty-Funktionen *schrittweise* in diese Doku eingeflechtet. /Was sie folgend als Beschreibung finden ist *keineswegs* vollständig!!!/ Man kann aber schon damit beginnen seine Programme anzupassen, um so in den Genuß der Liberty-Funktionen zu gelangen. Alles was folgend dokumentiert ist, wird sich *nicht* mehr ändern und kann demzufolge problemlos verwendet werden. 5.1 Allgemeines ================ Ich möchte an dieser Stelle nicht alles wiederholen was bereits oben beschrieben wurde. Daher nur nochmal ein Kurzüberblick über das, was Programmierer wissen müssen: ∙ Alle Liberty-Funktionen sind reentrant! Man braucht sich folglich *keine* Gedanken darüber machen, ob eine Funktion schon von anderen Programmen/Threads benutzt wird! ∙ Bevor man eine Liberty-Funktion aufruft sollte man lediglich sicherstellen, daß die Funktion genügend Stack zur Verfügung hat. Genügend heißt dabei *1k*! Mehr ist auf keinen Fall nötig, dieser Platz sollte aber bereitgestellt werden. ∙ Liberty verändert keine Registerwerte in einer Funktion. ∙ Wenn eine Liberty-Funktion einen Rückgabewert liefert, sollte dieser auch geprüft werden, um die korrekte Abarbeitung der Funktion festzustellen. ∙ AUF JEDEN FALL nur dokumentierte Funktionen und Eigenschaften nutzen! ∙ Jeden Hinweis auf Umgang mit Funktionen *genaustens* beachten. Wenn eine Variable als 'Read-Only' gekennzeichnet wurde, sollte man sie auch nicht überschreiben! ∙ Um Doppeldeutungen zu vermeiden: Ein Programm welches Liberty benutzt wird folgend immer als 'Applikation' bezeichnet. Das sollte man im Hinterkopf behalten... 5.1.1 Parameterübergabe ------------------------ Für die Parameterübergabe gelten die Regeln von Turbo C / Pure C: _Parameterübergabe Pure C (Auszug aus der Online Hilfe von PureC)_ ∙ Die ersten drei Variablen vom Typ char, int oder long werden in den Registern D0, D1, D2 übergeben. ∙ Die ersten zwei Adressparameter (Pointer) werden in den Registern A0 und A1 übergeben. ∙ Weitere Parameter, die keinen Platz mehr in den Registern D0, D1, D2, A0 A1 finden werden über den Stack übergeben. ∙ Parameter werden in der Reihenfolge von rechts nach links übergeben. _Beispiel:_ extern void lbf(int x1, int y1, int x2, int y2, int *l, int *b, int *f); main() { int x1 = 10, y1 = 10, x2 = 20, y2 = 20, l, b, f; lbf(x1, y1, x2, y2, &l, &b, &f); } Da mehr Werte-, als auch Adress-Parameter an die Funktion "lbf" übergeben werden, als Register zur Verfügung stehen, benötigen wir also in jedem Fall den Stack. Der vierte Werte-Parameter muß auf dem Stack abgelegt werden. Ebenso findet der dritte Adress-Parameter keinen Platz in den Registern, so daß auch dieser auf dem Stack abgelegt werden muß. In den Registern befinden sich: D0: x1 (Wert von x1) D1: y1 (Wert von y1) D2: x2 (Wert von x2) A0: &l (Adresse der Variablen l) A1: &b (Adresse der Variablen b) Auf dem Stack befinden sich: &f (hi) (höchstwertiges Wort im Stack) &f (lo) y2 (Wert von y2) Return- (Rücksprungadresse) Adresse (Stackpointer zeigt hierauf) Der Adress-Parameter f wird nach der Regel "von-rechts-nach-links" zuerst auf den Stack gelegt. Danach kommt der Wert von y2 auf den Stack. Bitte beachten Sie, daß die Rücksprungadresse des Unterprogrammes als letzter "Parameter" auf den Stack gelegt wird, so daß die Parameter im Stack ab dem Offset 4 anfangen. y2 (Offset 4), &f (Offset 6)! In C räumt die aufrufende Funktion nach dem Aufruf die Parameter selbst vom Stack (z.B. mit ADDQ.W #8,A7", nach einem Aufruf mit zwei Adressparametern). Dies erübrigt sich natürlich, wenn alle Parameter in Registern übergeben wurden. 5.2 Der Liberty-Cookie & XBIOS-Erweiterung =========================================== Liberty legt beim Start im Auto-Ordner einen Cookie-Jar an und erzeugt einen Keks namens 'Lity' dessen Inhalt auf eine Struktur weist, die dem beigefügten '.h'-File und dem entsprechendem Kapitel (Die Liberty-Struktur) entnommen werden kann. Da Liberty XBIOS-Funktionen installiert, die einen komfortablen Zugriff auf den Cookie-Jar ermöglichen, kann auf sehr einfache Art und Weise das Vorhandensein von Liberty festgestellt werden. Dazu ein Ausschnitt aus dem '.h'-File: #define CJar_xbios 0x434A /* "CJ" */ #define CJar_OK 0x6172 /* "ar" */ #define COOKIE_LIBERTY 0x4C697479L /* "Lity" */ #define CJar( mode, cookie, value ) xbios(CJar_xbios,mode,cookie,value) Folgendes 'Programm' prüft somit, ob die Systemerweiterung vorhanden ist: Liberty_Cookie *libfuncs; if (CJar(0, COOKIE_LIBERTY, &libfuncs)==CJar_OK) { printf("LIBERTY vorhanden!!!"); } else { printf("LIBERTY nicht vorhanden!!!"); } Bevor ein Programm Liberty benutzt, sollte auf jeden Fall durch obiges Verfahren festgestellt werden ob Liberty überhaupt vorhanden ist! Ist dies nicht der Fall muß das Programm gegebenenfalls terminiert werden. _Zu den verschiedenen Modi:_ Der erste Parameter der dem Makro 'CJar' übergeben wird, bestimmt den Modus der Cookie-Aufrufs. Im Gegensatz zum Original 'Cookie Jar Manager' von Dan Wilga (Liberty ist voll zum 'JARXX' kompatibel, man benötigt es also nicht mehr), existieren sogar 3 Modi zur Keks-Manipulation: ∙ Modus 0: Ermittelt den Wert des Kekses und legt in an der angegebenen Adresse ab. Übergibt man für 'value' einen NULL Pointer, so wird lediglich die Existenz des Kekses überprüft. Bei erfolgreicher Ermittlung des Kekses, liefert der Aufruf 0x6172 (="CJar_OK") zurück sonst einen anderen Wert. ∙ Modus 1: Erzeugt einen neuen Keks (cookie). Value *zeigt* auf einen Wert der in den Jar eingetragen wird. WICHTIG! Es wird nicht 'value' eingetragen sondern der Wert auf den 'value' weist!!! Bei Übergabe eines NULL-Pointers wird 0 als Kekswert eingetragen. Existiert der Keks bereits, so wird sein alter Inhalt überschrieben! Die Funktion liefert "CJar_OK" bei erfolgreicher Eintragung. -1 wird für den Fall geliefert, daß der Cookie-Jar voll ist! ∙ Modus 2: Entfernt den Keks 'cookie' aus dem Jar. Der Wert von 'value' ist egal. Liefert bei erfolgreicher Entfernung "CJar_OK" sonst einen anderen Wert. 5.3 Die Liberty-Struktur ========================= Der Inhalt des Liberty-Cookies weist auf folgende Struktur: typedef struct { WORD version; /* Hexadezimale Version. (0x0100 = 1.0) */ WORD gdriver; /* Unterstützes Grafiksystem (READ_ONLY!): * 0 = keins -> Standardformat (SLOW!!!) * 1 = ATARI Grafiksystem (IBPs) * 2 = NOVA Grafikkarten (Intel-Zahlenformat) * 3 = andere Grafikkarten/Mac? (Motorola) * Wert ist bis zur Version 1.5 ungültig!!! */ */ Lity_Utils *misc_funcs;/* Zeiger auf diverse Routinen */ Lity_GDExt *gd_funcs; /* Zeiger auf die 'GEMDOS'-Erweiterungen */ Lity_VDIExt *vdi_funcs; /* Zeiger auf die 'VDI'-Erweiterungen */ Lity_AESExt *aes_funcs; /* Zeiger auf die 'AES'-Erweiterungen */ Lity_SNDExt *snd_funcs; /* Zeiger auf Sound-Funktionen */ } Liberty_Cookie; Neben der Versionsnummer und dem Code für das unterstützte Grafiksystem findet man hier fünf weitere Zeiger auf Strukturen die folgend erläutert werden. 5.4 Die Utility-Funktionen =========================== Die Funktionen die man hier vorfindet lassen sich nicht einer bestimmten Kategorie unterordnen. Die Struktur enthält mehr oder weniger 'zusammengewürfelte' Funktionszeiger: typedef struct { LONG (*Init_Liberty)(WORD g_handle); void (*lock_Sema)(BYTE *semaphore); void (*release_Sema)(BYTE *semaphore); void (*memcpy)(void *dest, void *src, ULONG len); void (*memset)(void *dest, int val, ULONG len); } Lity_Utils; 5.4.1 Init_Liberty(); ---------------------- bekommt als Eingabeparameter das Handle der physikalischen VDI- Workstation, in der Form wie es vom AES-Call 'graf_handle()' geliefert wird. Der Rückgabewert ist reserviert. *Diese Funktion ist vor allen anderen Liberty-Funktionen aufzurufen (abgesehen von der XBIOS-CJar-Erweiterung)!* Da der Aufruf von graf_handle() unbedingt _nach_ einem appl_init() zu erfolgen hat (Stichwort: korrekte Applikationsprogrammierung), muß der appl_init()-Aufruf logischerweise vor dem graf_handle()-Aufruf erfolgt sein. Die Reihenfolge der Initalisierung kann man auch dem Programmbeispiel entnehmen. 5.4.2 lock_Sema(); ------------------- Setzt (z.B. für Prozesskommunikation) eine Semaphore, dessen Adresse übergeben wird. Wer mit dem Begriff 'Semaphore' nichts anfangen kann, wird diese Funktion wahrscheinlich auch nicht benötigen. 5.4.3 release_Sema(); ---------------------- Gibt eine 'gelockte'-Semaphore wieder frei. 5.4.4 memcpy(); ---------------- Bei dieser Funktion handelt es sich um das altbekannte 'memcpy' jeder 'string.h'-C-Biblothek, welches einen Speicherbereich vorgegebener Länge kopiert. Warum dieser Funktion in Liberty aufgenommen wurde? Weil viele Programme (inkl. Liberty selbst) diese Funktion benötigen und das Benutzen der Funktion via Liberty ein wenig Speicher bei Applikation einspart. (Vorausgesetzt man verwendet wirklich *nur* das Liberty 'memcpy()'!) 5.4.5 memset(); ---------------- Für 'memset()' (ebenfalls eine Standard-C Funktionalität) gilt das gleiche wie schon bei 'memcpy()' beschrieben. Nur das diese Funktion zum Setzen eines Speicherbereiches auf einen bestimmten Wert verwendet wird. 5.5 Die 'GEMDOS-Erweiterungen' =============================== Die Struktur 'Lity_GDExt' enhält fünf Funktionen die alle 'GEMDOS'- charakteristisch sind. Hauptsächlich dienen die Funktionen der Kontrolle über die Liberty Speicherverwaltung: typedef struct { Meminfo * (*CK_init_meminfo)(Meminfo *info, BOOLEAN app); void * (*CK_malloc)(Meminfo *info, const long size, const WORD type); void * (*CK_realloc)(Meminfo *info, const void *block, const LONG newsize); void (*CK_free)(const Meminfo *info, const void *ptr); void *reserved; void * (*CK_load_buffer)(char *filename, Meminfo *info, WORD type, LONG addmem, LONG *buflen); } Lity_GDExt; /Die Form der 'Meminfo'-Struktur entnimmt man der beigefügten '.h'- Datei./ 5.5.1 CK_init_meminfo() ------------------------ Eine Applikation die die Liberty-Speicherverwaltung nutzen will, muss bevor sie Speicher via Liberty anfordern kann drei Dinge tun: 1. Eine globale Variable des Typs 'Meminfo' bereitstellen... 2. Eine globale Variable der Typs 'Meminfo*' (Zeiger auf eine 'Meminfo'-Struktur' anlegen 3. und diese durch Zuweisung des Rückgabewertes der Funktion 'CK_init_meminfo()' initalisieren. Als ersten Parameter muss man dabei die Adresse der globalen Meminfo- Variablen übergeben (siehem auch Programmbeispiel). /Was ist der Sinn dieser Aktion?/ Liberty untersucht je nach Betriebssystem und Startmodus (ACC/APP) ob es die Meminfoblöcke verschiedener Liberty-Applikationen zusammenlegen kann, um eine effizientere Speicherverwaltung zu ermöglichen. Folglich muss der Zeiger den man als Rückgabewert erhält nicht identisch mit der Adresse des eigenen 'Meminfo'-Blocks sein. *Dieser Zeiger (Rückgabewert) ist aber der einzige, der bei allen nachfolgenden Liberty-Funktionsaufrufen die nach einem entsprechenden Typ verlangen übergeben werden darf.* _Außerdem:_ Jeglicher Inhalt der 'Meminfo' (Struktur-)Variablen darf von der Applikation *nicht* angetastet werden! Liberty obligt die volle Kontrolle dieser Struktur! Ein Verändern der 'Meminfo'-Inhalte führt unweigerlich zur totalen Verwirrung der Speicherverwaltung und Systeminstabilität ist die Folge! Der zweite Parameter des 'CK_init_meminfo()'-Calls (app) besagt, ob die Applikation als eine solche (1) oder als Accessory (0) gestartet wurde. Zur Ermittlung dieses Wertes verwendet man das landläufige Verfahren welches im Profibuch (10. Auflage) Seite 541 beschrieben ist. /Im Falle der Verwendung von PureC kann man auch gleich die Variable des PureC-Startup-Codes '_app' benutzen (wie auch im Programmbeispiel), oder man setzt den Parameter, für den Fall daß die Applikation nur als eine solche und nicht als Accessory gestarted werden darf, gleich statisch auf 'TRUE'./ Noch etwas: Natürlich sollte man in seiner Applikation nur /eine/ Speicherverwaltung nutzen. Die Vermischung von Speicheranforderungen via z.B. GEMDOS, C- Library und Liberty führen zwar nicht zur Applikationsinstabilität, aber sind alles andere als guter Programmierstil, da schwer kontrollierbar (welchen Block muß ich wie freigeben) und ineffizient. Die Verwendung der Liberty-Speicherverwaltung sollte ohnehin alle Speicheranforderungsbedürfnisse des Programmierers befriedigen und ein Mischen von Aufrufen unnötig machen. 5.5.2 CK_malloc() ------------------ Diese Funktion fordert Speicher vom System an. Im Gegensatz zum GEMDOS werden aber kleinere Speicherblöcke automatisch in grösseren Blöcken gehalten um evt. Betriebssystembeschränkungen zu umgehen. Die Verwaltung der Blöcke ist äußerst effizient, schnell und sollte auf jedem Fall andern Speicheranforderungsmechanismen vorgezogen werden, da auch noch andere Argumente für die Verwendung der Liberty- Speicherverwaltung sprechen: ∙ Liberty sorgt auch bei Accessories unter Single TOS für ein 'festes' Malloc. Normalerweise gehört Speicher, der nachträglich von Accessories unter Single TOS angefordert wird der aktuellen Hauptapplikation und /nicht/ dem Accessory. Das führt beim Beenden der Hauptapplikation zu ungewolltem Speicherverlust seitens des Accs und ist eine häufige Fehlerquelle. Dieses Problem existiert bei Verwendung der Liberty- Speicherverwaltung nicht mehr! ∙ Liberty ermöglicht eine optimale Verwaltung von Speicher auch unter Systemen mit Speicherschutz ('Memory-Protection'). Bei der Anforderung von Speicher via 'CK_malloc()' kann die gewünschte Speicherart übergeben werden (Parameter 'type'): MM_STGLOBAL bei Übergabe dieses Speichertyps fordert Liberty globales (ungeschütztes) ST-RAM an (z.B. für 'Message-Puffer') MM_STPRIVATE Liberty fordert privates (geschütztes) ST-RAM an MM_TTGLOBAL hier fordert Liberty *vorzugsweise* globales (ungeschütztes) TT-RAM an. Steht nicht genügend TT-RAM (wird auch als 'Fast-RAM' bezeichnet) zur Verfügung, wird automatisch (globales) ST-RAM angefordert. MM_TTPRIVATE Liberty versucht privates (geschütztes) TT-RAM zu reservieren. Steht nicht genügend TT-RAM zur Verfügung, wird automatisch (privates) ST-RAM angefordert. Dieses ist wohl der am häufigsten verwendete Typ der Speicheranforderung ('schnell & sicher'). Das Besondere der Speicheranforderungen seitens Liberty besteht nun darin, dass die Speicherblöcke je nach tatsächlich vorhandener Speicherart optimiert gehalten werden. Mit anderen Worten: Exisitiert nur globaler Speicher (weil z.B. die Applikation unter einem Betriebssystem gestartet wurde welches nur 'nicht privaten Speicher' unterstützt) werden alle Anforderungen von privatem Speicher in Anforderungen von globalem Speicher umgesetzt. Dieses Verfahren spart dadurch sogar z.T. das Anfordern von neuen GEMDOS-Systemblöcken und damit Speicherplatz. ∙ Die Speicherverwaltung von Liberty prüft einige Kriterien ob der von ihr verwaltete Speicher durch eine Applikation korrumpiert wurde. In diesem Fall erhält man entsprechende Fehlermeldungen auf dem Bildschirm. So wird man auf Applikationsfehler bei der Verendung von Speicher hingewiesen, was bei der Entwicklung von Programmen kein unwesentlicher Punkt ist. Doch zurück zum 'CK_malloc()': Neben der Übergabe des zuvor beschriebenen 'Meminfo'-Pointers wird noch die anzuforderne Blockgrösse in Byte sowie der oben schon beschriebene Speichertyp mit übergeben. Der Rückgabewert ist ein Zeiger auf den Block oder 'NULL' falls entsprechener Speicher nicht angefordert werden konnte (Speicherknappheit). 5.5.3 CK_realloc() ------------------- Diese Liberty-Routine arbeitet analog zum C-'realloc()' und dem Liberty-'CK_malloc()'. / Eine Speichertypänderung ist *nicht* möglich!/ 5.5.4 CK_free() ---------------- ist die Implementierung des C-'free()' der Liberty-Speicherverwaltung. 5.5.5 CK_load_buffer() ----------------------- Wie oft kommt es vor das ein Programmierer eine Datei in einen Puffer laden muß und jedesmal die gleiche Sequenz von Funktionsaufrufen getätigt wird... Damit sollte nun Schluss sein. Die Parameter der Liberty-Buffer-Lade- Funktion sollten eigentlich selbsterklärend sein, hier aber trotzdem die Übersicht: filename Dateiname der zu ladenen Datei info der schon bekannte Meminfo-Pointer type anzuforderne Speicherart addmem Anzahl der Bytes die zusätzlich anzufordern sind. Diese sind nach dem Laden der Datei am Ende des Buffers und unbelegt. Die Funktion liefert einen Zeiger auf den angeforderten und geladenen Buffer oder 'NULL' falls ein Fehler aufgetreten ist (Datei konnte nicht geladen werden, zu wenig Speicher vorhanden etc.). Jetzt kommt's: Als besonderes Schmankerl kann die Buffer-Laderoutine aber noch mehr: Dateien die mit dem 'ATOMIK'-Packer gepackt wurden (ein äußerst effzienter Packer dessen Dateien zusätzlich auch noch flink zu dekodieren sind) werden automatisch ausgepackt! Das Packen ist z.B. sinnvoll bei MOD-Files, bestimmten Grafikformaten, archivierten Texten oder sonstigen einteiligen, großen Dateien die nicht oder sehr selten angetastet werden. 5.6 Die 'VDI-Erweiterungen' ============================ Hier kommt noch etwas hin... 5.7 Die 'AES-Unterstützung' ============================ Hier kommt noch etwas hin... 5.8 Die Sound-Funktionen ========================= Hier kommt noch etwas hin... 5.9 Programmbeispiel ===================== Das Programmbeispiel geht davon aus, daß die '.h'-Dateien 'LIBERTY.H' und 'IBMR.H' in Standard-Include-Verzeichnis des C-Compilers liegen. Das hier gezeigte Beispiel demonstriert die Initalisierung der Library und Speicherverwaltung unter PureC: #include <liberty.h> #include <stdio.h> #include <stdlib.h> #include <stddef.h> #include <aes.h> #include <vdi.h> #include <tos.h> Meminfo minfo, *mi; /* Applikations Meminfo-Block und Zeiger */ void main(void) /* Dieses Programm macht nix... */ { Liberty_Cookie *libstruct; Lity_GDExt *gdfuncs; int d1, d2, d3, d4, grhandle; appl_init(); /* ...obwohl es einige Programmierer noch nicht begriffen haben: DAS GEHÖRT SICH SO! */ if (CJar(0,COOKIE_LIBERTY,&libstruct) != CJar_OK) { form_alert(1,"[3][This Application needs LIBERTY to run...][Exit!]"); appl_exit(); return; } vh = graf_handle(&d1, &d2, &d3, &d4); libstruct->misc_funcs->Init_Liberty(grhandle); /* Liberty initalisieren */ gdfuncs = libstruct->gd_funcs; /* ...trägt nur zur Lesbarkeit bei... */ mi = gdfuncs->CK_init_meminfo(&minfo,_app); /* Speicherverwaltungsinit */ /* HIER STEHT DAS EIGENTLICHE PROGRAMM ! */ /* ...für Meminfos wird jetzt immer 'mi' übergeben !!! */ if (_app) /* Applikation ? */ appl_exit(); /* raus... (MT-OS Behandlung der Einfachheit wegen weggelassen) */ else for (;;) /* Beim Acc sporadisch */ evnt_timer(0,32000); /* beenden */ } 6 Ausblick *********** Zum Zeitpunkt dieser Veröffentlichung von 'Liberty' sind die Raster- grafikfunktionen leider alles andere als komplett. Damit aber andere schon jetzt zumindest in den Genuß der restlichen Liberty Funktionen kommen, habe ich mich dennoch für die Herausgabe der Library im nicht vollständigem Zustand entschieden. Erste Erweiterung wird folglich darin bestehen, den Rastergrafikteil vollständig auszubauen. Aber auch im Vektorgrafikteil fehlen noch einige wünschenswerte Zusatzfunktionen. Wie danach die Weiterentwicklung verläuft ist schwer zu sagen. Hauptsächlich hängt das von meinen eigenen Bedürfnissen ab. Selbst- verständlich können auch Wünsche anderer Programmierer die Liberty nutzen (wollen) den Funktionsumfang erweitern. Jedoch werde ich strikt darauf achten, daß Liberty nie mehr als 50k Speicher schluckt und nicht zum schon beschriebenen 'Klotz' wird. Welche Funktionen Liberty bietet kann dem 'einfachen' Anwender eigentlich egal sein. Er kommt meist unbemerkt in den Genuß der Funktion, sobald ein Programm sie benutzt. Das einzige worauf ein Anwender achten sollte ist, daß er möglichst immer die neuste Liberty-Version installiert hat. Da Liberty benutzenden Programmen beigefügt werden darf, dürfte diese Forderung leicht zu erfüllen sein. 7 Changes ********** *Änderungen Version 1.31* ∙ Einen Fehler in der Speicherverwaltung von Liberty behoben, der dafür verantwortlich war, daß unter 'Single TOS' mit alternativem Speicher bei Anforderung von ST-RAM trotzdem alternatives RAM angefordert wurde. Dadurch blieb z.B. die Soundausgabe bei obiger Konfiguration stumm. ∙ Das Problem der Applikations-ID-Vergabe unter NAES gemildert: Liberty kann nun AES-Calls bis zur AP-ID 128 verarbeiten (war 64). Dennoch: Dadurch das NAES immer die AP-ID seiner Prozesse hochzählt und unbenutze IDs nicht neu vergibt, ist nach 128 Applikationsstarts Schluß mit den AES-Features von Liberty. Die Auswirkung: Freedom2 kann nicht mehr von Applikationen mit IDs jenseits von 128 aufgerufen werden. Das Problem läßt sich in Liberty nicht auf einfache Art lösen, eine weitere Steigerung des ID-Raumes würde viel zusätzlichen Speicher verschlingen. NAES verhält sich in diesem Punkt anders, als alle anderen TOS- kompatiblen Betriebssysteme. Ich hoffe also das sich in NAES da noch etwas tut ;-). ∙ ...viel, viel zu tun... *Änderungen Version 1.30* ∙ Ich kann's nicht fassen. Unsaubere Applikation bringen mich irgendwann einmal noch um den Verstand. In dieser Version habe ich DEFINITIV die letzte Änderung am Schweineprogrammbehandlungsteil vorgenommen. Eine Sonderbehandlung für MTOS/NAES und MagiC soll nun maximale Kompatibilität auch bei unsauberen Programmen bringen. U.a. profitieren dadurch auch ältere Versionen von MGCOPY,MGVIEW etc., die, was die Sauberkeit der Systemanbindung anging, noch nicht so prall waren. Die jetzige Schweineprogrammbehandlungsroutine ist *definitiv* der Weisheit letzter Schluss! Da OAESis nicht ein vernünftiges appl_find(NULL) anbietet, sondern ziemlichen Blödsinn macht, kann ich OAESis *nicht* empfehlen. Liberty es ist praktisch unmöglich Liberty&Freedom2 unproblematisch unter OAESis zum Laufen zu bringen. Aussagen über GENEVA und XAES kann ich nicht treffen. _WICHTIG:_ Damit Liberty ordnungsgemäß unter MagiC arbeitet, ist eine MagiC-Version >= 3.x unabdingbar!!! ∙ Besitzer von Rechnern mit DMA-Sound ((Mega)STE, TT) kommen nun endlich auch in den Genuß der Liberty-Soundfunktionen. Neben Macs mit 'MACSOUND' und Falcons kommt bei diesen Rechnern nun also auch Freude auf, wenn man im Freedom2 Info-Dialog auf das große 'Freedom-Logo' klickt... (wenn die Software der Startrack-Karte für den HADES auch einen 'McSn'-Cookie anlegt (tut sie das? wer sagt's mir?), bekommen die HADES-User auch was zu hören...) ∙ Weitere Beschreibungen von Liberty für Programmierer in die Doku integriert. *Änderungen Version 1.20* ∙ Endlich arbeitet Liberty mit NAES korrekt zusammen. Was war die Ursache? Na ? - Die Schweineprogrammbehandlung. Ohne einen Anruf von Rainer Mannigel (NAES-Entwickler) wäre das wohl nie etwas geworden. Durch ihn habe ich von einer NAES internen Sache erfahren und das ermöglichte mir Liberty darauf abzustimmen. Ich hoffe den Schweineprogrammbehandlungsteil nun nicht mehr anfassen zu müssen... ;-) *Änderungen Version 1.15* ∙ Liberty ist jetzt /noch/ rücksichtsvoller Schweineprogrammen gegenüber und billigt ihnen mehr SV-Stack zu. (Das kostet 5k mehr... :-() Dadurch läuft jetzt Liberty mit dem VT52 Emulator in der Version 1.3 zusammen was einem Benutzer ;-) besonders wichtig war... ∙ Das 'free' der Speicherverwaltung von Liberty erlaubte nicht das Freigeben eines NULL-Pointers, was aber offiziell dokumentiert ist. *Änderungen Version 1.1* ∙ Liberty benutzt jetzt ein anderes Verfahren um schweinische AES- Calls zu 'reparieren'. Damit sollten (hoffentlich) die Probleme die im Zusammenhang mit 'Calamus96' auftreten der Vergangenheit angehören. Ich möchte ausdrücklich betonen, daß die Probleme von 'Calamus96'-Modulen ausgehen und Liberty jetzt nur /noch/ rücksichtsvoller mit unsauberen Programmen umgeht. Gleiches gilt auch für 'OverPaint' (getestet mit der Demo-Version 1.5s). Ich weise in diesem Zusammenhang darauf hin, daß das neue Verfahren mehr Zeit benötigt und es dadurch zu (merklichen) Performance-Verlusten bei unsauberen Programmen kommen kann! (...aber lieber ein langsam ablaufendes Schweineprogramm als ein abstürzendes... - oder?) Nochmals meine Bitte an alle Programmierer: Achtet bei AES- Aufrufen darauf, daß ihr einen *korrekten/initialiserten* und *vollständigen* AES-Parameterblock verwendet!!! ∙ Es liegt ein Patchfile für MacSnd dabei. Das entsprechende Kapitel beachten! ∙ Die ersten Beschreibungen von Liberty für Programmierer in die Doku integriert. ...to be continued 8 Kontaktadresse ***************** Falls Sie irgendwelche Fragen, Probleme oder Wünsche bezüglich Liberty haben sollten, können Sie mich unter folgender Adresse erreichen: Christian Krüger Im Erpelgrund 16 13503 Berlin Internet email: chris@pace.de *Wichtig:* Wer Kontakt via Sackpost zu mir aufnehmen will, der sollte (wenn er eine Antwort erwartet) einen an sich adressierten und ausreichend frankierten Rückumschlag beifügen! Man kann mich auch anrufen, aber *_bitte_* nur von Mo-Do in der Zeit von 20:30-21:00 Uhr oder 22:00-22:30 Uhr! Wer zu anderen Zeiten die (030) 436 27 85 wählt braucht sich nicht zu wundern, wenn er entweder niemanden erreicht oder mich ziemlich sauer oder kurz angebunden an die Strippe bekommt! Von privaten Besuchen bitte ich abzusehen, die Erfolgschancen mich anzutreffen sind ohnehin ziemlich gering. Außerdem bitte ich alle Anwender der Library nur dann zu mir Kontakt aufzunehmen, wenn unlösbare Probleme oder gravierende Mängel bei der Installation der Library auftreten! (Ich verstehe darunter das man sich mindestens 2x die Liberty- Dokumentation durchgelesen hat und immernoch nicht schlauer ist!!!) Zeit die ich mit der Beantwortung von Fragen verbringe steht mir nicht mehr zum Programmieren zur Verfügung... (Ein gutes und hilfreiches Forum um solche Fragen evt. zu klären stellt die "Hotline der Share-/ Freeware", das Maus-Netz, Gruppe 'atari.soft' dar. Wären hier nicht viele hilfsbereite und kompetente Menschen zugegen, die bei Fragen zu Programmen durch ihre Beantwortung für die Programmautoren einspringen, wer weiß ob Liberty hätte jemals entstehen können... Ich widme daher diese Library allen Atari-Enthusiasten im Maus-Netz - *Danke!* :-) ) /Rächtzszeibunsfälör by Zeitmangel und Portfolio-Tastatur!/